home *** CD-ROM | disk | FTP | other *** search
NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNAAAAMMMMEEEE netsnoop - capture and decode network traffic SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ////uuuussssrrrr////ssssbbbbiiiinnnn////nnnneeeettttssssnnnnoooooooopppp [----LLLL _p_r_o_t_o_c_o_l_s] [----bbbb _b_u_f_f_e_r] [----cccc _c_o_u_n_t] [----dddd] [----eeee _f_l_a_g_s] [----hhhh _h_e_x_p_r_o_t_o_s] [----iiii _i_n_t_e_r_f_a_c_e] [----llll _l_e_n_g_t_h] [----nnnn _n_u_l_l_p_r_o_t_o_s] [----oooo _t_r_a_c_e_f_i_l_e] [----pppp _p_r_o_t_o_p_t_s] [----qqqq _l_i_m_i_t] [----tttt _i_n_t_e_r_v_a_l] [----rrrrssssvvvvxxxxyyyy] [_f_i_l_t_e_r ...] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _N_e_t_s_n_o_o_p captures packets which match an optional _f_i_l_t_e_r from a network _i_n_t_e_r_f_a_c_e or saved _t_r_a_c_e_f_i_l_e. If _f_i_l_t_e_r is omitted and no ----eeee option is given, it captures packets promiscuously. For each packet, _n_e_t_s_n_o_o_p prints decoded frames of protocol data on standard output. It stores captured packets in a buffer before decoding them; the default buffer size is one. After decoding buffered packets, _n_e_t_s_n_o_o_p resumes capturing. Only the superuser can run _n_e_t_s_n_o_o_p on a local network interface. Users accepted by the _s_n_o_o_p_d(1M) authorization file on a NetVisualyzer station can _n_e_t_s_n_o_o_p from interfaces on that host. OOOOppppttttiiiioooonnnnssss -L _p_r_o_t_o_c_o_l_s List information on standard output about the symbols and options defined by _p_r_o_t_o_c_o_l_s, a comma-separated list of protocol names. List information defined by all protocols if _p_r_o_t_o_c_o_l_s is aaaallllllll. If _p_r_o_t_o_c_o_l_s or a part of it has the form _p_r_o_t_o_c_o_l._n_a_m_e, list information about _n_a_m_e only. ----LLLL causes _n_e_t_s_n_o_o_p to ignore other options and to exit after listing protocol information. -b _b_u_f_f_e_r Set the capture buffer size to _b_u_f_f_e_r packets. -c _c_o_u_n_t Stop capturing after receiving _c_o_u_n_t packets that match _f_i_l_t_e_r. All _c_o_u_n_t packets are buffered before they are decoded; that is, ----cccc _c_o_u_n_t implies ----bbbb _c_o_u_n_t. -d Dump entire packets in hexadecimal rather than decoding them symbolically. This option overrides the partial hex dump options ----hhhh and ----xxxx. -e _f_l_a_g_s Capture packets received with the data link errors specified by _f_l_a_g_s, a comma-separated list of flag names. The following flags are supported: aaaannnnyyyy, ffffrrrraaaammmmeeee, cccchhhheeeecccckkkkssssuuuummmm, ttttoooooooobbbbiiiigggg, ttttoooooooossssmmmmaaaallllllll, nnnnoooobbbbuuuuffffssss, oooovvvveeeerrrrfffflllloooowwww, and mmmmeeeemmmmoooorrrryyyy. See _s_n_o_o_p(7P) for more about _n_e_t_s_n_o_o_p error flags. If the _f_i_l_t_e_r argument is omitted, _n_e_t_s_n_o_o_p captures only packets received non-promiscuously with the specified errors. Otherwise it captures both packets matching _f_i_l_t_e_r and packets received with errors. -h _h_e_x_p_r_o_t_o_s Dump the frames for the protocols named in the comma- separated _h_e_x_p_r_o_t_o_s list in hexadecimal rather than decoding them symbolically. PPPPaaaaggggeeee 1111 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) -i _i_n_t_e_r_f_a_c_e Snoop on the network associated with _i_n_t_e_r_f_a_c_e. By default, _n_e_t_s_n_o_o_p captures packets from a host's primary interface. _I_n_t_e_r_f_a_c_e may name a network interface, a host that addresses a configured interface, an interface on a host (_h_o_s_t:_i_f_n_a_m_e) running _s_n_o_o_p_d, or a tracefile created by the ----oooo option. Invoke _n_e_t_s_t_a_t(1M) with the ----iiii option to list configured interfaces and their hostnames. -l _l_e_n_g_t_h Set the length in bytes of packet data to capture. By default, _n_e_t_s_n_o_o_p captures all bytes of packet data. -n _n_u_l_l_p_r_o_t_o_s Do not decode or dump frames for the protocols named in the comma-separated _n_u_l_l_p_r_o_t_o_s list. -o _t_r_a_c_e_f_i_l_e Output undecoded packets to _t_r_a_c_e_f_i_l_e. By deferring packet decoding until a subsequent _n_e_t_s_n_o_o_p invocation, this option improves capture effectiveness. It typically produces a smaller tracefile than would result from redirecting decoded output. -p _p_r_o_t_o_p_t_s Set protocol options. Each option in the comma-separated _p_r_o_t_o_p_t_s list has one of these forms: _p_r_o_t_o_c_o_l._o_p_t_i_o_n _p_r_o_t_o_c_o_l.nnnnoooo_o_p_t_i_o_n _p_r_o_t_o_c_o_l._o_p_t_i_o_n=_v_a_l_u_e Use nnnneeeettttssssnnnnoooooooopppp ----LLLL _p_r_o_t_o_c_o_l to list a protocol's options. -q _l_i_m_i_t Reserve _l_i_m_i_t bytes for packet buffering in _n_e_t_s_n_o_o_p's kernel input queue. The default reservation is 60000 bytes. -r Decode received sequence numbers rather than numbers rewritten to count only matches against _f_i_l_t_e_r and reception gaps. -s After decoding, print statistics telling how many packets were received by the network interface, and how many were subsequently dropped due to kernel resource limits. -t _i_n_t_e_r_v_a_l Capture for _i_n_t_e_r_v_a_l seconds. This option may be used with ----cccc to capture at most _c_o_u_n_t packets in a given _i_n_t_e_r_v_a_l. -v Verbose decoding: decode more packet fields. This option accumulates, so ----vvvvvvvv causes _n_e_t_s_n_o_o_p to show a very verbose representation of protocol data. -x Dump packet data not interpreted by protocol decoders in hexadecimal. PPPPaaaaggggeeee 2222 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) -y Consult the NIS name service when translating numbers to names. By default, _n_e_t_s_n_o_o_p uses local databases such as /_e_t_c/_h_o_s_t_s and /_e_t_c/_s_e_r_v_i_c_e_s. FFFFiiiilllltttteeeerrrr SSSSyyyynnnnttttaaaaxxxx _N_e_t_s_n_o_o_p concatenates all _f_i_l_t_e_r arguments after the last option and interprets the resulting string as an expression of operands joined by operators. Operands are sub-expressions, path expressions, C integer constants, or protocol-specific strings. All C operators except the assignment operators and ????:::: are supported. The keywords aaaannnndddd and oooorrrr may be used in place of &&&&&&&& and ||||||||, respectively. A single ==== may be used in place of ========. The keyword nnnnooootttt may be used in place of !!!!. Operators that are shell metawords must be quoted if _n_e_t_s_n_o_o_p is invoked from a shell. The subtraction operator ---- must be preceded by white space; otherwise it is taken to be part of a protocol-specific string (an IP hostname, for example). A path expression is a period-separated sequence of components, of which all but the last must be well-formed C identifiers. Each identifier except the last must name a protocol encapsulated by the preceding component's protocol, or a structured field in the last protocol. The first identifier in a path names a field in the network interface's data link protocol, or a network protocol encapsulated by the data link protocol. Supported data link protocols include 10 Mb/s Ethernet, 100 Mb/s FDDI, Serial Line IP, and the loopback pseudo-protocol. If the last identifier in a path expression names a protocol, then the expression evaluates to 1 given a packet containing the listed protocols' frames, nested in the expressed order; otherwise it evaluates to 0. If the last identifier names a protocol field of structure or array type, then the expression evaluates to 1 given a packet containing such a field, and to 0 otherwise. If the last identifier names a protocol field of scalar type, then the expression evaluates to the field's contents in host order, given a packet that contains the field and that matches the path preceding the field. If the last identifier names a protocol macro, _n_e_t_s_n_o_o_p parses the macro's definition in the preceding protocol's context. Otherwise the last component in a path must be a protocol- specific string, for example, the name of a well-known port. _N_e_t_s_n_o_o_p decodes a packet only if _f_i_l_t_e_r evaluates to a non-zero value. EEEErrrrrrrroooorrrr CCCCoooorrrrrrrreeeeccccttttiiiioooonnnn A filter may lack ==== (========) and aaaannnndddd (&&&&&&&&) operators in many cases. _N_e_t_s_n_o_o_p's filter parser will correct such errors by inserting the appropriate operator, based on the type of the operand to the left of the insertion point. For example, the filter ip.dst fergie udp.dport 1023 will be corrected as follows. First, the parser inserts ======== after iiiipppp....ddddsssstttt, because the latter is not a comparison: PPPPaaaaggggeeee 3333 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) ip.dst == fergie udp.dport 1023 Then, because no operator was found after the comparison iiiipppp....ddddsssstttt ======== ffffeeeerrrrggggiiiieeee, the parser inserts &&&&&&&&: ip.dst == fergie && udp.dport 1023 Finally, ======== is inserted after uuuuddddpppp....ddddppppoooorrrrtttt, for the same reason that ======== was inserted after iiiipppp....ddddsssstttt, above: ip.dst == fergie && udp.dport == 1023 _N_e_t_s_n_o_o_p prints the corrected filter enclosed by brackets ([]) before it starts capturing, so that the user can verify the correction. PPPPrrrroooottttooooccccoooollll SSSSttttrrrriiiinnnnggggssss Each protocol name in a path opens a scope containing resolved strings, such as hostnames and addresses. For example, the Internet Protocol (IP) resolves iiiipppp....bbbbrrrrooooaaaaddddccccaaaasssstttt to the IP broadcast address configured for the network interface being snooped, iiiipppp....nnnneeeettttmmmmaaaasssskkkk to the configured IP netmask, and 111199992222....22226666....77775555....11112222 to a four-byte IP address in host order. If a string occurs in an expression without a qualifying protocol path, _n_e_t_s_n_o_o_p tries to resolve it in the scope of the last protocol to its left in the expression's parse tree. If that fails, it tries the data link protocol's scope. Thus iiiipppp....ddddsssstttt====bbbbrrrrooooaaaaddddccccaaaasssstttt matches packets destined for the local network's IP broadcast address, while bbbbrrrrooooaaaaddddccccaaaasssstttt====iiiipppp....ddddsssstttt applied to an Ethernet interface cannot be parsed, because bbbbrrrrooooaaaaddddccccaaaasssstttt is unresolved in Ethernet's scope (but iiiipppp....bbbbrrrrooooaaaaddddccccaaaasssstttt====iiiipppp....ddddsssstttt parses). MMMMaaaaccccrrrroooossss Protocols define macros in their own scopes to provide manifest names for magic numbers and to provide shorthand for common lengthy expressions. For example, the Ethernet protocol defines BBBBRRRROOOOAAAADDDDCCCCAAAASSSSTTTT as the Ethernet broadcast address, ffffffff::::ffffffff::::ffffffff::::ffffffff::::ffffffff::::ffffffff. Protocols also define macros in encapsulating protocol scopes to provide nicknames for long protocol path expressions. For example, IP defines nnnnffffssss as a nickname for iiiipppp....uuuuddddpppp....ssssuuuunnnnrrrrppppcccc....nnnnffffssss in all data link protocols that contain iiiipppp. Macros may have arguments, which follow the macro name either separated by white space, or in a parenthesized, comma-separated list containing arbitrary white space. To define a macro in the subject interface's data link protocol, use ddddeeeeffffiiiinnnneeee((((_n_a_m_e,,,, _d_e_f)))). Calls to ddddeeeeffffiiiinnnneeee may be preceded by a protocol path, to define macros in higher-level protocols. Strings of the form $$$$_N within _d_e_f represent formal arguments to _n_a_m_e. Each such formal is replaced by the _Nth actual argument supplied when _n_a_m_e is called. The number of formal and actual arguments must agree. Calls to ddddeeeeffffiiiinnnneeee expand to 1111, so the ,,,, (comma) or &&&&&&&& (aaaannnndddd) operator must be used to join PPPPaaaaggggeeee 4444 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) definitions with expressions in a complex _f_i_l_t_e_r argument. OOOOuuuuttttppppuuuutttt FFFFoooorrrrmmmmaaaatttt Each decoded packet begins with a header telling its sequence number, length in bytes, and reception time. The sequence number starts with zero and counts only packets that match _f_i_l_t_e_r and packets dropped by the kernel, which are assumed to match (use the ----rrrr option to decode reception, rather than matched, sequence numbers). The reception time is displayed in hours, minutes, seconds, and microseconds. For packets received with errors, _n_e_t_s_n_o_o_p prints an exclamation point after the sequence number and prints error flag mnemonics after the reception time. After the header come lines containing decoded protocol data. Data are grouped into frames labeled by protocol names. Each frame consists of field names and field contents. Field names are as in filter expressions. By default, _n_e_t_s_n_o_o_p decodes only interesting fields within a frame. The ----vvvv option increases the level of decoding detail. With the ----xxxx option, any data not interpreted by protocol decoders is dumped in lines of hexadecimal (with ASCII), labeled by byte offset from the beginning of the packet. For example, below is the output of nnnneeeettttssssnnnnoooooooopppp ----vvvvxxxxcccc 1111 ttttccccpppp: 0000: len 102 time 11:40:31.925 ether: src 8:0:69:2:c:a7/SGI dst 8:0:69:2:31:30/SGI ip: len 44 id 6393 off 0 src twilight.wpd.sgi.com dst england.wpd.sgi.com tcp: sport 1023 dport 1021 seq 627,392,000 ack 0 flags SYN win 16,384 urp 0 maxseg 1460 00058: 00 00 00 00 00 06 ...... 00064: 00 14 7f 00 00 01 7f 00 00 01 00 6f 13 49 00 00 ...........o.I.. 00080: 00 00 00 00 00 00 50 00 00 00 00 00 00 00 00 00 ......P......... 00096: 00 00 ff eb .... EEEEnnnnvvvviiiirrrroooonnnnmmmmeeeennnntttt By default, _n_e_t_s_n_o_o_p maps names to numbers using local database files such as /_e_t_c/_h_o_s_t_s. The iiiipppp....hhhhoooossssttttrrrreeeessssoooorrrrddddeeeerrrr protocol option governs IP hostname/address resolution. See _s_e_t_h_o_s_t_r_e_s_o_r_d_e_r(3N) and _r_e_s_o_l_v_e_r(4) for the format of this option's value. _N_e_t_s_n_o_o_p caches name/number associations in protocol-specific files in /_t_m_p, so that subsequent invocations can more quickly map numbers that occur frequently in network traffic. Cache entries have a cache-specific ``time-to-live'' - older cache files are unlinked at startup, and reconstituted to contain new- found associations upon termination. When _n_e_t_s_n_o_o_p is started, it tries to read a file named ._n_e_t_s_n_o_o_p_r_c in the user's home directory. A valid ._n_e_t_s_n_o_o_p_r_c file consists of blank lines, comment lines beginning with ####, macro definitions, default command options, and protocol option settings. Macro definition have the form PPPPaaaaggggeeee 5555 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) define ip.udst ip.dst == $1 && udp.dport == $2 Default options may be set as follows: option -x -n ether Protocol options are set as with the ----pppp option (white space may be used as well as commas to separate options): set ip.noetherupdate arpip.noetherupdate _N_e_t_s_n_o_o_p's command line overrides ._n_e_t_s_n_o_o_p_r_c. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS To capture all packets received without errors and decode every byte in each packet, issue: netsnoop -vvvx To capture _r_l_o_g_i_n(1) traffic between jjjjaaaakkkkeeee and eeeellllwwwwoooooooodddd, issue: netsnoop ip.between jake elwood and tcp.port login The following invocation captures all packets, good or bad: netsnoop -e any 1 A constant non-zero filter expression must be used with ----eeee in order to capture all packets. Without the 1111, only bad packets destined for the snooping host would be captured. To capture 10 UDP broadcast packets from host jjjjaaaakkkkeeee, issue: netsnoop -c 10 udp and ip.src=jake and ip.dst=broadcast The following invocation captures NFS traffic from eeeellllwwwwoooooooodddd to jjjjaaaakkkkeeee, and makes use of error correction: netsnoop nfs ip.src elwood ip.dst jake [nfs && ip.src == elwood && ip.dst == jake] PPPPaaaaggggeeee 6666 NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) NNNNEEEETTTTSSSSNNNNOOOOOOOOPPPP((((1111MMMM)))) FILES .netsnooprc $HOME/.netsnooprc User customization file /tmp/.*.cache Protocol-dependent caches /usr/sbin/netsnoop Executable SSSSEEEEEEEE AAAALLLLSSSSOOOO analyzer(1M), snoopd(1M), ypfiles(4), ethernet(7), snoop(7P), _N_e_t_V_i_s_u_a_l_y_z_e_r _U_s_e_r'_s _G_u_i_d_e. BBBBUUUUGGGGSSSS You cannot start capturing based on match, interval, or count; nor is there an option to stop capturing based on match. PPPPaaaaggggeeee 7777 
